we need some introduction before describing the scenario because it feels like steep turn for this here and hard to catch what is this about

Thanks for your remarks. What would you suggest here?

The original prompt by Tushar was:

Write a guide about the batching capabilities of Tailcall. Consider a food delivery application where a lot of users are requesting the same data. Batching could be implemented based on GEO Location / City / Locality etc. Emphasize on the impact it has on performance and how it can help scale. Consider the backend to be in REST.

@meskill I've addressed your remarks by adding a preceding sentence. Please refer to commit a660f84.

• REduce the drama about "perks" and "remote work" and "slack bot"
• Talk about traffic surge during lunch hours. This is not just about orders, but also users in the same GEO location requesting for the same data again and again and the upstreams services serving literraly the same data to everyone. Instead having an orchestrator that could sit in between the frontend and the upstream services could very efficiently batch these request, reducing the load massively.

@tusharmath if upstream is repeatedly serving the same data to difference users, then the obvious solution here is caching and not batching.

This is why I didn’t dwell on concurrents users but on a single user performing multiple requests.

To my knowledge, there’s no way for Tailcall to batch requests from multiple users (read multiple simultaneous requests) into a single upstream request.

if upstream is repeatedly serving the same data to difference users, then the obvious solution here is caching and not batching.

Not necessary, caching is relevant when the data is changing. With batching enabled, we can serve multiple people the same data without requesting it multiple times upstream and can do it even if the data isn't cachable.

To my knowledge, there’s no way for Tailcall to batch requests from multiple users (read multiple simultaneous requests) into a single upstream request.

Check @server.batchRequest it allows tailcall to batch multiple requests.

@tusharmath
I feel like we are talking past each other here. Tailcall has two notions of batching but based on your feedback, it is not really clear which one you are asking for.

Inbound Batching

My understanding of batching in this context is similar to the concept of multiplexing in HTTP/2 as illustrated by the diagram in this SO answer:

As an example, an end user sends 5 different graphql requests in quick succession to the Tailcall server (this might happen on app load when trying to hydrate multiple view components). Because the 5 inbound requests were received within a few millis of each other, the Tailcall server can decide to queue all 5 responses so it can send only 1 response to the end user, if the Tailcall server was started with batchRequests option set to true.
This type of batching reduces the network round-trip from 5 responses down to only 1 response.

Outbound Batching

The Tailcall server needs to make a multiple outbound requests to another server using a combination of the @upstream operator and the @http operation. Instead of making 50 or 100 requests, one-by-one, Tailcall can batch them into a single outbound request. This type of batching is what I understood that the original article was asking for as can be seen in the diagram, examples and description.

The only way to use geo-location to improve response times for millions of end users trying to use a service is to either use geo-routing or introduce a CDN that is geo-aware to cache identical requests. It was hard to work either of those solutions into the article which is why I focused on the Slack command example.

In fact your last sentence in the original issue was: "Consider the backend to be in REST" and I asked clarifying questions under the assumption this would be an article about outbound batching on the original issue but never got any response.

Essentially, this would mean a complete rewrite of an article that took 2 months just to get feedback ...

@tusharmath no response ?

Hey @tusharmath
your response is needed to this question as it affects all of the feedback provided.

use excalidraw to create images.

Table isn't readable because we have too many columns. Flatten it into multiple paras.

Some context about error handling should also be added to this guide.

I think the head of the document is generally talking about REST & Batching. The jump to Tailcall is quite sudden. I would split this doc into two separate ones. The tailcall specific bits should be in the guide, the remaining stuff can be on our blogs.